Software programs are written for many different operating systems and hardware platforms. Often, there is a need to make a software program written on one platform (“source platform”) run on a different platform (“target platform”). The software program written for the source platform might not work on the target platform as there can be difference between the two platforms. These differences can be due to a variety of factors, such as hardware architecture differences, operating environment differences, etc. Also, as software products undergo continuous development, application programs written for older version can become incompatible with newer versions. The process of achieving a transfer from the source platform to the target platform is referred to herein as “migration”.
One particular known environment where migration can be desired, and where migration can encounter the foregoing problems, is where the target platform has a Solaris Operating Environment. For example, the source platform might be an earlier version of Solaris, or one of the Unix variants (HP-UX, AIX etc.) or completely separate platform, such as Windows NT. Most often, during the migration process, the programming language remains the same, but code that compiled flawlessly on the source platform has errors or incompatibilities when that same code is compiled on the target platform. Any incompatibilities between the source and target platform are referred to herein as “issues”. The issues can include, for example, hardware dependencies, operating system application program interface (“API”) call incompatibilities or build environment incompatibilities. The existing, manual migration process involves detecting these issues between the source and target platform and then resolving them in order to make the software system work on Solaris Operating Environment.
As will now be understood by those of skill in the art, the migration process has a number of challenges to solve. Software systems to be migrated can range from a few thousand lines of code to several million lines of code. Yet the current, manual migration process requires quick identification of migration issues without extensive knowledge of the overall software system. Furthermore, it is usually desired to carry out the migration process in short period of time—especially when compared to accepted time frames for program maintenance. Software maintenance is continuous effort while migration is a one-time effort, usually performed under time constraints. Furthermore, the process of manual migration can be hampered because the software to be migrated may be old and include minimal or no documentation. In general, migration is carried out by people who are unlikely to be the original creator or maintainer of the software, therefore adding time and complexity to the process of manual migration. Manual migration of software typically requires the professional conducting the manual migration to have knowledge of both the source and target platform and, in addition, to know all the issues that exist between the two platforms. Such resources are expensive and not readily available.
Another problem with manual migration is knowing whether the software program to be migrated from the source platform is actually complete—i.e. whether the entire software program has been provided to the person conducting the migration—thus requiring the person conducting the migration to detect missing pieces of the system. Doing this task manually can be error prone and costly.
Yet another problem with manual migration is the lack of a database of issues that are known to exist between the source and target platforms. Such a database has to be built over a period of time by capturing the issues encountered through various migration projects, but which are typically only compiled in a manual fashion.
Attempts have been made to use existing maintenance and reverse engineering tools to automate the migration of software between platforms, but generally these tools provide unsatisfactory and/or somewhat deficient results. In general, such prior art tools are not geared specifically to the problem of migration of software, but rather towards the more general area of software maintenance and reverse engineering. Further, these tools do not include databases of known issues, or the means to gradually build such databases. Further, such prior art tools generally lack built-in means to detect migration issues, and there is generally no overall framework for easily plugging in different parsers and analyzers to use with different source languages
Certain other prior art tools are targeted towards the more specific problem of migration from a specific source platform to specific target platform, but lack general flexibility to migrate between a plurality of different source platforms and/or a plurality of different target platforms. In general, prior art tools are geared towards reverse engineering or program maintenance. One of the aims of such tools is building high level models for the software systems in order to assist in program understanding and are generally built for continuous maintenance. Prior art tools are generally not geared towards migration of software within a short time frame. Many prior art tools run on only a specific platform and require significant initial setup time. Still other prior art tools lack robust parsers capable of parsing incomplete source code from the source platform, and provide poor or no facilities to record the differences detected during a migration process in order to assist in future migration.